1. Field of the Invention
The present invention relates generally to the field of networking. Specifically, the present invention relates to platform independent alert detection and management.
2. Background of the Invention
As the size and complexity of computer networks continues to grow, so too does the time required to maintain such networks. It is not uncommon for local area networks that once required only a single network administrator to now require multiple administrators or even a dedicated network support department.
As networks continue to grow in size, they likewise grow in complexity. Nowadays, it is rare for networks to contain devices that were all produced by the same manufacturer. More likely, whether because of price, availability, or otherwise, a given network will contain a mixture of computers and appliances, produced by various manufacturers. Furthermore, the wide selection of central processing units, audio and video components, storage devices, and other support hardware available for both computer systems and peripherals has enabled custom configuration of systems tailored to meet particular needs.
Unfortunately, however, from a network administration or management perspective, the more diverse a network is, the more difficult it is to manage due to the varying hardware and software configurations utilized by the varying devices or clients. Traditionally, when a networked device ceased to function on a network, the network administrator would personally visit the device to troubleshoot the cause of the malfunction. In a large network containing many clients, however, the process of locating a client, not to mention the process of troubleshooting, can be time consuming and therefore costly.
Remote management tools have been developed as part of an effort to decrease the total cost of ownership of networked systems by increasing their manageability. Typically, remote management tools provide system administrators with a means for detecting client malfunctions located remotely from the administrator. Unfortunately though, the notification that the administrator receives may be limited merely to an indication of whether an event has occurred, rather than a preferred notification indicating what type of event has occurred. Likewise due to the varying degree of customization within network devices, the event notification may not be tailored to the specific device that generated the event. Thus, an improved approach to event notification is desired.
Furthermore, although remote detection of a malfunction may be possible using a management tool, a personal visit by an administrator remains necessary in order to attempt to remedy the problem. Although notification of a malfunction or system alert is important, it is also desirable to have the capability to remotely act on the information to correct a failing condition. Since a large portion of malfunctions cause client operating systems to “hang”, “freeze” or “lock-up”, it is further desirable for a mechanism that provides the ability to perform remote operations on a client after boot, to also provide the ability to perform such operations when the client is without a functioning operating system, or in pre-boot state.